변경에 유연한 컴포넌트

• 제품을 만들 때, 비즈니스의 확장과 변경을 대비할 수 있어야 하는데 미래를 누구도 예측할 수는 없다. 그렇기에 변경에 그나마 유연하게 대응할 수 있도록 코드를 작성해야 하는 것이다.

컴포넌트

• 시스템을 UI로 보고, UI를 구성하고 있는 요소를 컴포넌트라고 한다.
• 컴포넌트 기반으로 개발하여 반복되는 요소들 간의 일관성을 유지할 수 있고, 만드는데 필요한 비용을 절감할 수 있다.
• UI의 일관성을 유지하고 비용을 절감한다는 것은 컴포넌트가 제대로 나눠졌을 때의 이야기

컴포넌트의 역할

1. 외부로부터 주입된 데이터 관리
   1. api, local storage등 외부 리소스로부터 전달받은 데이터
   2. 부모 컴포넌트에서 전달되는 데이터
2. 데이터를 UI로 표현한다.
   1. React와 같은 라이브러리들은 화면에 보여지는 페이지 중심이 아니라 데이터(state 등) 중심으로 돌아감. 그렇기에 컴포넌트에서 관리하고 있는 데이터를 화면에 어덯게 렌더링할 지 선언하면 됨
3. 사용자로부터 인터랙션을 받는다.

1. 데이터 기반 설계

예상 가능한 Props 디자인

1. 기본 attributes
   1. 기본 attribute 중 역할과 일치하는 것이 있으면 그것을 사용하는 것이 좋음
   2. <select></select> element역할을 수행하는 컴포넌트의 props 디자인은 <select></select> element를 따라가는 것.
   3. onValueChange같은 네이밍이 아닌 onChange라는 이름으로 디자인하는 것
2. 역할이 드러나는 네이밍
3. 널리 사용되는 네이밍
   1. 디자인 시스템 오픈소스 라이브러리 참고하기
      1. Radix
      2. chakra
      3. React Spectrum

추가

1. 컴포넌트를 분리하는 것은 재사용에만 있는 것이 아니다. 복잡도를 찾추기 위해 적당히 컴포넌트를 분리하는 경우도 있기 떄문이다. 보통 이렇게 분리된 컴포넌트는 기존 컴포넌트으 ㅣ복잡도를 낮춰 가독성을 좋게 한다는 느낌을 준다. 컴포넌트가 복잡해졌다면 먼저 UI 로직을 추상화하여 복잡도를 낮출 수 없는지 고민하자.
   • 추상화란 불필요한 정보를 제거하고 문제 해결에 필요한 정보만 남기는 작업
2. 나중에 리팩토링할게요 금지
   1. 리팩토링은 엄청나게 큰 변화를 일으키는 작업이다. 변경이 없는데도 변경이 발생하는 것이다. 이 변경으로 인해 문제가 없는지 살펴봐야 하는 사용자 인터페이스가 많아질수록 버그가 발생할 확률이 높아진다.
      • 리팩토링은 반드시 필요한 작업이다. 하지만 아쉬벡도 나중에 리팩토링할 시간은 쉽게 주어지지 않는다.

Refernce

변경에 유연한 컴포넌트